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The role of the data base system of the Loop Maintenance Opera- 
tions System (lmos) is to maintain up-to-date information about the 
customer's telephone service and trouble history to facilitate customer 
trouble repair. The discussion covers data base content, rationale for 
the data base system architecture, and methods for keeping the data 
current. 

I. OVERVIEW— LMOS 

To provide an understanding of the data base system issues of lmos, 
this overview shows functional linkage between the various system 
parts and briefly discusses the host architecture design, data base 
conversion, and data base update. The remaining sections of the paper 
provide detailed discussions of the evolution of the host data base 
system architecture, data base conversion strategy, and methods and 
types of data base update required to keep the operational data base 
current. 

The Automated Repair Service Bureau (arsb), described in this 
issue of The Bell System Technical Journal, 1 ' 2 consists of two major 
functions: mechanized management of customer repair data and mech- 
anized testing. The lmos, a distributed system, is the customer repair 
data management system. The lmos host maintains customer line 
record and trouble data so that repair personnel have up-to-date 
information about the facilities being repaired. The lmos front-end 
transaction processors record and track troubles on telephone equip- 
ment from the time the troubles are reported until they are repaired. 

For simplicity, discussion of other arsb systems, such as Mechanized 
Loop Testing (mlt), Loop Cable Administration and Maintenance 
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Fig. 1 — Loop maintenance operations system (lmos). 

Operations System (lcamos), and Trouble Report Evaluation and 
Analysis Tool (treat) are not covered in this paper. See Refs. 3, 4, 
and 5 appearing in this issue. 

1.2 System organization 

Figure 1 illustrates geographic overlay of the system on a typical 
Bell operating company's (boc's) area of application (from five to 
seven million lines) and the trouble processing functions supported by 
major elements of the system. 
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The lmos host data base stores in a large "master data base" 
complete information on the customer's telephone service including 
premise equipment data; class of service; network facilities assigned to 
the customer's circuit; and trouble history. In the example lmos 
geographic area of Fig. 1, complete "line card" and trouble history files 
for all customer lines in the five-to-seven-million-line area of applica- 
tion exist in the host data base. 

The distributed front-end transaction processors form the real-time 
interface with customers via the Centralized Repair Service Answering 
Bureau. 6 An lmos installation can have up to 12 front-end transaction 
processors. The maximum capacity of a single transaction processor is 
approximately one million lines. The actual number of transaction 
processors installed will depend on considerations such as transaction 
rates and area boundaries. 

In the example shown, we assume seven transaction processors, each 
mapping into one of the subareas A through G. The data base for each 
front-end processor contains a subset of the line record data in the 
host and is called a miniline record. The miniline record contains 
essential information for repair and is used principally for trouble 
report taking. If the host is down, the miniline record can also provide 
basic information for processing troubles to a "closed" status. It is 
about one-seventh the size of the full line record on the host. In 
addition, a given transaction processor contains miniline records only 
for customers in its subarea. 

1.3 Trouble processing 

Figure 1 also illustrates how the distributed architecture of lmos 
supports customer report processing. Assume the customer's phone 
service is in subarea G and is out-of-order. The customer may report 
the trouble from any location within the total area; however, the cross 
front end links the Centralized Repair Service Answering Bureau with 
the front-end data base serving subarea G, while the trouble report is 
being taken (event l). 7 When the trouble report is forwarded to 
transaction processor G, it requests a Basic Output Report (bor) from 
the host. The bor, containing complete line record data, test results, 
and trouble history, is transmitted to a printer in the rsb serving that 
customer (event 2). The bor is screened for the appropriate next step, 
which may include further tests, a craft dispatch or other activity as 
required to repair the trouble (event 3). When the telephone circuit is 
repaired, trouble report closeout information is transmitted to the host 
(event 4). 

1.4 Host data base architecture 

Figure 2 shows the architecture of the lmos host data base system. 
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The three host software generics on the left keep the data bases 
current. To the right are data base interfaces with the front-end 
transaction processors and the statistical report generation software, 
Trouble Report Evaluation and Analysis Tool (treat). 5 Major divi- 
sions of data are as follows: 

Past trouble history — The Abbreviated Trouble History (ath) data 
base contains, as a minimum, the most recent 40 days of history. The 
Trouble History (th) data base contains histories of troubles closed 
during the day and is used to support treat statistical reports. 

Line record — These data bases contain information about the cus- 
tomer's telephone circuit. The Plain Old Telephone Service (pots) and 
Special Services (ss) data bases are identical structures, except the 
pots key is the 10-digit telephone number, while the ss key can be any 
alpha-numeric up to 16 characters, plus number plan area (npa). These 
two data bases form the basic line record information. (Note that for 
lmos convenience, the lmos definition of an ss is any circuit having 
an identifier that is other than 10-digit numeric with a real npa.) The 
Cable (ca), Associated Number (an), Telephone Answering Service 
(tas) and Central Office Equipment (coe) data bases contain data 
common to the line record file but have been "inverted" for access by 
cable and pair number, telephone number associated with a main 
account, tas number associated with a customer's telephone service, 
and central office exchange key and switching equipment number, 
respectively. 

Miniline record— These are reduced versions of the pots and ss line 
record data bases described above. There is one miniline record data 
base for each front-end transaction processor; the miniline record 
provides the mechanism for transferring changes that have occurred 
in the host to the front end. 6 

Service order history — This data base contains a list of all line 
records changed during the day. The list is used for constructing 
niiniline records to be sent to the front ends. 

1.5 Data base conversion and update 

The three modes for processing changes to the host data base are 
LOAD, Automatic Line Record Update (ALRU), and ON-LINE. The 
LOAD subsystem is used to initially create the line record data base 
from existing paper records or from other mechanized sources. The 
ALRU automatically performs the bulk of day-to-day changes to the 
records because of service order activity. The ON-LINE subsystem 
provides a means for manual inspection and/or change of line record 
information via a crt; the principal uses of this subsystem are error 
correction, input of nonstandard service orders, and input of informa- 
tion as a result of plant rearrangements and changes (work orders). 
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Audits provide for internal consistency between common data items 
in the various data bases. Accuracy checks usually require data com- 
parison to physical circuits. 

1.6 Data base decisions in retrospect 

The data base system of lmos had to accommodate the following 
major repair functions: 

(i) Taking trouble reports— The operational objective was to dis- 
play, in five seconds or less, information about a customer's telephone 
service when the customer contacted the Centralized Repair Service 
Answering Bureau. 

(ii) Tracking open troubles — The system had to provide a capa- 
bility for accepting new trouble reports "and maintaining status infor- 
mation about the troubles until closed out. 

(Hi) Maintaining trouble history — The most recent forty days of 
closed trouble information had to be maintained in the data base for 
summary and review purposes. Afterwards, the trouble history data 
could be transferred to microfilm storage. 

(iv) Maintaining up-to-date line record data — Changes made to 
the customer's telephone service had to be reflected (typically within 
24 hours) in the lmos data bases. 

While the above list is not exhaustive, it does show a requirements 
pattern for the data base system. Functions (i) and (ii) require the 
data base system to provide rapid access to data and to manage volatile 
trouble report information while the trouble is being processed. Func- 
tions (Hi) and (iv) are characterized by long-term storage of large 
amounts of data that change relatively slowly (i.e., 1/3 to 1/2 percent 
of the data changes every working day). 

It was decided that functions (i) and (ii) could best be met with 
small data bases distributed across several front ends. These data 
bases would contain copies of essential line record data (miniline 
record) obtained from a large master data base. The master data base 
(referred to in this paper as the lmos host data base) would be the 
focal point for all updating and distribution of line record changes 
throughout the lmos system. 

Using redundant storage to meet response time requirements some- 
what complicates the data base update process, but time constraints 
on update are much less severe and the penalty was considered worth 
paying. In addition, the power of a large main frame machine (host 
machine) could be effectively used to update the master data base and 
to propagate changed miniline records to the front-end data bases. 

Regarding data base conversion, another judgment made early in 
the program was not to require boc's to purify records prior to lmos 
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load. The rationale was twofold. First, the repair operations suffered 
mostly from lost records as opposed to inaccurate records. With lmos, 
the line record would always be available and at a quality level with 
which the boc chose to operate. This philosophy significantly reduced 
data base conversion expense. Secondly, tools were provided in lmos 
to permit gradual record quality improvement if desired by the boc. 
This basic decision is one of the main reasons that lmos has gained a 
rapid market penetration. 

1.7 Summary 

This overview has summarized the lmos data base system from the 
viewpoints of trouble processing flow and data base architecture to 
support this flow. Advantages being realized by the distributed data 
base architecture described include the following: 

(i) Use of inexpensive minicomputers as transaction processors 
with small data bases while taking advantage of the Information 
Management System (ims) data management system for manipulating 
large data bases on the host. 

(ii) Availability of several highly reliable transaction processor 
configurations for real-time customer interaction. 

(Hi) Ability to locate the transaction processor near the rsbs being 
served to minimize communications costs. 

To date, the data base design has served the loop repair process 
well. At the end of 1980, approximately 50 million customer line 
records were resident in lmos installations throughout the Bell Sys- 
tem. This huge reservoir of data (60 billion bytes) is now being viewed 
as a system resource that will undoubtedly be tapped to support other 
loop operations in addition to repair. 

II. DATA BASE ARCHITECTURE OF LMOS 
2. 1 Evolution of architecture 

Architecture of the data base system of lmos has evolved from the 
centralized data base design of the prototype system installed in the 
first trial company in 1972. 1,2 Experiences with that system and addi- 
tional data needs of the second and third boc customers forced changes 
in the data base structure. 

The prototype system divided the line record data between two data 
bases, pots and ss, to allow use of ims's fastest access method for the 
pots data base. The prototype system installed in December, 1972, 
contained data that today is kept on the front end. At that time, the 
line record data bases also contained data about open troubles on the 
circuit. The trouble history (th) data base contained both trouble 
history and history of changes to the line record data bases, called 
service order history. 
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During the early months of the first trial company's conversion, 
projections indicated that a pots data base for a 2.5-million-line system 
would span twenty 3330 Model 1 disk packs, making the necessary 
backup and recovery processes intolerably slow and unmanageable. 
The two line record data bases were split into seven pots data bases 
and three ss data bases, and a "WHICH" table was added to tell which 
data base contained a line record, given the exchange (nnx) of the line 
record key. 

Data base lockout problems were experienced because, at that time, 
IMS prevented access to the entire data base while updating a record. 
To reduce the incidences of lockout, two new data bases were created: 
one for the open trouble data that resided in the line record data base 
and one for the service order history data that was in the th data base. 

The open trouble data base was moved to the front-end system with 
the introduction of the distributed lmos in the second boc in 1974. 
(The th data base remained on the host because the data base was so 
large.) Since the lines covered by the second installation included 
different area codes (npas), npa was added to the line record key and 
the WHICH table was expanded to include npa with the nnx. 

The structure of the pots data bases changed again before installa- 
tion in a third boc in 1975. This boc has many nnxs in which the 
assigned telephone numbers fall predominantly in certain thousands 
(last 4 digits) groups. For instance, there might be 800-900 numbers of 
the form 8611xxx, but less than a hundred of the form 8612xxx. Since 
the data base design at that time allocated space on a switching entity 
basis (10,000 records), this would have resulted in very large pots data 
bases with many records having unassigned numbers. The data base 
was redesigned to allocate space on one-thousand group entities rather 
than ten-thousand group entities, thus, reducing wasted storage space. 

The principal lesson learned from the introductory experience is 
that the repair operation environment varies widely from company to 
company. It is strongly recommended, prior to the introduction of 
major mechanized systems, that prototype "soaks" in at least two 
companies having widely different geographic environments be per- 
formed. 

2.2 Current architecture 

The lmos host data base structures are hierarchical. The structure 
of the line record data base serves as an example. The line record data 
base contains a root segment for data that is constant in length and 
almost always present. Examples are the line record key (telephone 
number or circuit number), central office equipment, listed name, 
repair route, indicator for special service protection, essential line 
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number, and class of service. Variable length data items are kept in 
child segments having the following structure names: 

LCLOC Line Card Location — Contains additional listed name, 
service address, and location information. (The first 55 
bytes only are stored in the root segment.) 

LCRMKR Line Card Remarks, Retained — Contains remarks to 
inform the repair technician about access and equip- 
ment information. 

LCSE Line Card Service and Equipment — Contains codes for 

customer's service and equipment. 

LCSEN Line Card Service and Equipment Narrative — A child 
segment of LCSE that contains narrative about the 
service and equipment. 

LCCL Line Card Cable — Contains cables and pairs assigned to 

the circuit. 

LCCLN Line Card Cable Narrative — A child segment of the 
LCCL that contains cable narrative, binding post, and 
terminal address data. 

LCISG Line Card Incoming Service Group — Contains hunting 
data. 

Figure 3 shows the line record structure. Any of the child segments 
may have multiple occurrences. The customer trouble processing 
operation frequently results in having to access line record data when 
the telephone number or circuit number is not available, but, one of 
the following is: 

(i) Central office equipment number 
(ii) Cable pairs 
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Fig. 3 — Line record structure for pots and ss data bases. 
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(Hi) Main telephone number if the circuit is part of a multiline 
account 

(iu) Board, position, and jack if the circuit has telephone answering 
service. 

This access capability was implemented by building four inverted 
data bases rather than using the secondary indexing provided by IMS. 
Access through the secondary index would have been too slow and 
data base reorganizations would have been required too frequently. 
The price for the inverted data bases is that the update programs must 
consistently update two data bases every time one of the data items is 
added or deleted; when programs have bugs, inconsistencies between 
the line record data base and the inverted data bases result. This 
points to the need for a common data base access routine (which has 
not yet been implemented). 

The four inverted data bases are described below: 
(i) Cable (caJ — The ca data base contains a segment for each 25- 
pair complement within the cable. Associated with each pair is a pah- 
status, taper code, pair use, and telephone number if the pair is 
working. Multiple telephone numbers working on the same pair are 
listed in separate child segments. 

(H) Associated number (an) — Large business accounts have a main 
account telephone number that is used for billing and other central 
functions. All other telephone numbers assigned to that business are 
known as associated numbers. The an data base contains a root 
segment for a main account telephone number and a child segment for 
each associated number. A program performing a disconnect of a large 
business account would use this data base to find all the line records 
to update. 

(Hi) Central office equipment (coe) — The coe data base contains a 
segment for each piece of coe. Multiple telephone numbers working 
on the same equipment are kept in a separate child segment, one for 
each additional number. A separate data base, the coe parameter data 
base, contains the range of allowable coe numbers. This data was 
separated from the coe data to reduce the disk space needed for the 
coe data. 

(iv) Telephone answering service (TASj — The tas data base con- 
tains a root segment for each telephone answering service board and 
position number. Two occurrences of a child segment exist to associate 
the telephone number of tas customers with their jack numbers, one 
for jacks 1-49 and one for jacks 50-99. Multiple circuits working off 
the same jack are kept in a third-level segment. 

Brief descriptions of the other lmos data bases follow. 

(i) Miniline card (mlcJ — The mlc data bases provide the mech- 
anism for transferring changes that have occurred in the host data 

1 140 THE BELL SYSTEM TECHNICAL JOURNAL, JULY-AUGUST 1 982 



base to the front-end data bases. There are up to 12 mlc data bases in 
the host, one for each front-end system. At the end of every day, a 
miniline record is constructed from each line record that was changed 
during the day. These miniline records are placed in the mlc data 
bases. During the following day, the front-end system asks for the new 
miniline records to refresh its miniline record data base, which is used 
for trouble report processing. 

(ii) Service order history (sohJ — The soh data base contains a list 
of line records that were changed. After the miniline records are built 
and placed in the mlc files, the soh data base is reinitialized. 

(Hi) alru messages (alrumJ and alru recovery monitoring 
(ARM)— The Automatic Line Record Update (alru) system (described 
below) uses these two data bases. The alrum data base collects error 
messages during the alru run. When alru finishes, the messages are 
sorted and distributed, and the data base is reinitialized. The arm data 
base contains data useful for alru recovery and monitoring. 

(iu) Cable fail (cfJ — The cf data base contains a list of all cables 
for which a known cable failure exists. 

(v) Trouble history (th) — The th data base contains trouble 
history for all troubles closed during the day. At the end of the day, 
the front-end system sends trouble history data to the host to populate 
this data base, which is the primary input to the Trouble Report 
Evaluation and Analysis Tool (treat). The th data base is reinitialized 

daily. 

{vi) Abbreviated trouble history (athJ— The ath data base con- 
tains a subset of the data in the th, but it keeps, as a minimum, the 
most recent 40 days of trouble history. 

(vii) Pending service order (psoJ— The pso data base contains the 
text of pending service orders by main account telephone number. The 
bor checks this data base to warn the repair technician of any pending 
work on the telephone number. About half of the lmos companies 
have implemented this data base since its utility varies from company 
to company. 

(viii) Completed service order (csoj— The cso data base contains 
the text of completed service orders by main account telephone num- 
ber. These orders are used primarily for reference when correcting 
errors generated by alru. As above, about half of the lmos companies 
have implemented this data base. 

2.3 Data base sizing for a typical BOC 

For a five-miUion-working-line system, the lmos host data bases will 
contain about six billion bytes of data, and the total of all lmos front- 
end data bases will contain about 1.3 billion bytes of data. The "per 
line" average is shown in Table I. 
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Table I — Average bytes of data per line record 



Host Data Base 


Bytes 


Front-End Data Base 


Bytes 


Line record 

Cable 

Office equipment 

Associated number 

Telephone answering 

Closed troubles 
All other 
Total (per line) 


790 

250 

45 

(negligible) 

60 

75 

1220 


Miniline record 
Open troubles 
Testing, other 

Index to open troubles and 
line records 

Total (per line) 


130 

30 
30 

70 
260 



Note that the front-end data base miniline record contains only 15 
percent of the host line record data, since the front end must contain 
only that data subset required for on-line customer trouble report 
processing when the host is down. 

Figure 4 is a display of a miniline record. The corresponding host 
line record is shown in Fig. 5. Note the additional information the host 
line record contains. The line record lists customer service and equip- 
ment codes and accompanying narrative (s&e), retained remarks 
(rmk), which may contain premises access information, the vertical 
termination of the originating equipment (vt), party position number 
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Fig. 4 — Miniline record. 
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DLR DLRL EC 444 TN 713 4921000 


SEC DPA 


PRTR 


T998 PAGE 
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•END 


OF DATA 









Fig. 5— Full line record. 

if the customer has party service, and a complete list of other circuits 
participating in a sequential hunt group (htg). The example indicates 
that the customer is a telephone answering customer (tac) and is 
connected to a telephone answering service (tas) board with telephone 
number 7134921111 at position 1 on jack 4. While the miniline record 
has a limit of 55 characters for name, address, and location, the host 
line record can contain up to 823 characters. Finally, the miniline 
record has a limit of five cable pairs, but the host line record contains 
the complete cable pair list and any accompanying cable narrative. 
Considering the total "per line average" storage requirements per 
customer, the front-end storage space per customer is about 20 percent 
of the host storage space per customer. Assuming a five-million-line 
system using five front ends, the storage space per front end is met by 
two DEC RP06 disc storage units (1200 cylinders). The host storage 
requirements are met by approximately 30 IBM 3350 direct access 
storage devices (dasds). 

III. BUILDING THE OPERATIONAL DATA BASES 

This section describes the lmos host procedures to 
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(i) initially load the data bases when lmos is first installed, and 
(ii) merge additional data into the data bases when repair entities 
are added. 

3.1 Initial load 

In preparation for data base loading, boc personnel must assemble 
the paper records and other data sources currently used in the repair 
operations and convert these data to machine readable form. Accuracy 
checks on the data prior to loading lmos are not required since lmos 
provides internal consistency checks and data correction capabilities 
based on conflicts and errors observed by the field craft. 

A total of nineteen jobs must be run to complete the initial host 
data base load. Figure 6 summarizes the flow of these nineteen steps 
and partitions the steps into four major loading functions: 
(i) Build skeleton history and message data bases 
(ii) Initialize data base to accept only that data falling in specified 
ranges. 

(Hi) Perform validation checks on line record data and partition 
data by principal data bases 

(iv) Load the principal data bases (line record data base and in- 
verted data bases). 

After the principal data bases are loaded, audits of data validity and 
consistency must be performed. Audit programs fall into two cate- 
gories. The "self check" class of audit programs scan the line card, 
central office equipment, and cable files independently, looking for 
load errors, such as two or more telephone numbers connected to the 
same central office equipment terminal. The "cross-check" class of 
audits compares common data in the inverted files (an, coe, tas, and 
ca) to the line record files (pots and ss). These data must be consistent; 
therefore, if a discrepancy is found, the line record file is assumed to 
be accurate and the cross-audit program automatically updates the 
inverted file to agree. 

3.2 Merge load 

The lmos data base is typically loaded in phases (by rsb) until the 
entire locality served by the host is populated. For example, customer 
data for additional switching machine entities or rsbs can be added to 
the data base by performing steps 7 through 19 (using merge options) 
of Fig. 6. 

IV. KEEPING THE DATA BASE CURRENT 
4. 1 Data Input sources 
For our purposes, the telephone network can be divided into two 
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Fig. 6 — Steps required for initial lmos host data base load. 

major pieces: the loop portion (i.e., from the end office to customer 
premises) and the toll portion (the remaining network that intercon- 
nects that national long-distance facilities). While the toll portion of 
the network is relatively stable, the loop portion undergoes constant 
change because it is the customer interface with the total network. 

Since the lmos data base is customer (and, thus, loop) oriented, 
these changes must be tracked. Activities that generate data base 
changes fall into two basic categories: (i) customer initiated service 
requests, and (ii) Bell operating company initiated plant changes. 
These categories are described below: 
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4.1.1 Customer initiated service requests 

These requests are typified by a customer calling the local Residence 
Service Center/Business Service Center (rsc/bsc), or stopping by a 
phone center store, to request telephone service for a newly completed 
home or business. Other types of requests include rearrangement or 
addition of station equipment for an existing service, household moves, 
and changes to class of service. 

The fundamental loop network record of these requests, and subse- 
quent changes made to the customer's service and facilities, is the 
Universal Service Order (uso). Figure 7 provides an example of a 
completed service order (i.e., all work to implement the customer's 
request has been completed) for a simple pots service. 

The service order header is the only "fielded" portion of the order 
and contains record identification information, such as the telephone 
number for the account and service order number. 

The listing section contains customer's name and location infor- 
mation; the billing section is of minor interest to lmos; the service 
and equipment section identifies service features, quantity, and circuit 
arrangements for station equipment; and the assignment section iden- 
tifies the central office and outside plant facilities. 

Standards for the machine-readable uso are documented by AT&T. 

4.1.2 Bell operating company initiated plant changes 

The boc's engineering and construction forces are charged with 
having adequate facilities in place at the right locations to meet 
customer service requirements. The requests that stimulate additions 
and rearrangements to loop plant are called work orders (sometimes 
called job orders). 

Examples of work orders include the following: 
(i) Cable throw — A new cable may be installed to augment an 
existing cable feeding a high growth area. To achieve desirable cable 
pair utilization levels (fill level), a range of cable pairs in the old cable 
can be freed up and reassigned to the new cable. This involves a 
change to the customer's cable and pair number. 

(ii) Area transfer — It is occasionally necessary to do wire center 
load balancing for growth. One method is to reassign customers in a 
geographic serving area from one wire center to another, or to a newly 
installed central office switch. This usually involves customer feeder 
cable changes and frequently involves change of customer telephone 
number. 

The above are only two examples of a variety of work orders. The 
record format and content of completed work order forms depend on 
the type of order worked. 
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Fig. 7— Example service order. 

4.2 Service order processing 

Because service orders are written in uso language, they can be 
processed by machine. Each boc has a mechanized service order 
network that produces a daily tape of completed service orders for 
updating the lmos host data bases. 

Before lmos programs can read these service orders to update the 
data bases, the orders must pass through a boc written interface 
program to add rsb identifiers (repair unit numbers) needed by lmos 
and to translate boc unique data to the standard uso format. 

The lmos programs that update the data bases from service order 
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input form the alru system. The alru comprises two program func- 
tions, the service order reader and the packet processor. The service 
order reader parses service orders, extracts data of interest to lmos, 
and produces "packets," which are groups of data that correspond to 
the lmos data base structure. Among the packets produced from the 
service order in Fig. 7 would be a packet to 
(i) create a new line record, 
(ii) install the listed name and address, 

(Hi) install the service and equipment data on the line record, 
(iv) install the repair route on the line record, 
(v) install the office equipment on the line record and update the 
coe data base, 

(vi) install the cable data on the line record and update the ca 
data base, 

(vii) install coe remarks on the line record, and 
(viii) install assignment remarks on the line record. 
The packet processor reads the packets and updates the data base. 
The number of packets produced for each service order will vary, 
depending on service order type and complexity. Based on field expe- 
rience, a typical lmos installation may process 20,000 orders, or about 
200,000 packets a day. 

4.3 Work order processing 

Unlike the service order, the work orders today are not written in a 
uniformly structured language. Hence, the "load" generic and the "on- 
line" generic are used to input work order data to the lmos host (see 
Fig. 2). If the work order involves a bulk change of data, such as 
throwing 400 pairs from cable 102 to cable 109, the bulk cable throw 
batch program of the load generic accomplishes this very efficiently. 
If, on the other hand, only a few pairs are to be "thrown," say five 
pairs, the enter cable change (ecc) transaction of the on-line generic 
would be the best choice to use. Changes made to the host data base 
by using batch programs of the load generic, or by using the various 
transactions available in the on-line generic, are propagated to the 
front-end data bases in the same way that service order changes are. 

4.4 Data base update summary 

Figure 8 provides an encapsulated view of the lmos data base update 
processes described in this paper, and how those processes interface 
with the boc's service order and work order flow. 

First a summary of the service order flow as shown by the solid lines 
in Fig. 8: 

1. The customer requests new or changed telephone service. 
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2. The request is entered into the boc's service order network to be 
"worked." 

3. A request is made to assign facilities necessary to install or modify 
the customer service. 

4. Facilities are assigned and information is forwarded to the service 
order network. 

5. Service order network forwards information to do work to the 
installer. 

6. Installer completes work, returns notice to service order distri- 
bution network that service order has been completed. 

7. Completed service order goes to boc interface program to perform 
selected data translations for "standard" alru input. 

8. A day's worth of service orders are accumulated and read into 

ALRU. 

9. Automatic Line Record Update automatically updates the host 
data base. 

On the average, there is one service order processed per line per 
year. A typical 5-million-line lmos installation will process about 
20,000 service orders per working day. 

A summary of the work order flow as shown by the dashed lines of 
Fig. 8 follows. 

1. The Distribution Services Design Center forwards requests for 
loop facility additions or rearrangements to the Construction Mainte- 
nance Center to be worked. In addition, other work centers may 
request work to be performed. For example, the repair forces may 
request work to be performed to repair a trouble (maintenance change 
request). 

2. If the request for work involves existing facilities, facility assign- 
ment information is requested. 

3. Facilities assigned to the work order are forwarded to the Con- 
struction Maintenance Center. 

4. The construction craft receives the complete work instructions. 

5. Work is completed and notices sent to the Construction Mainte- 
nance Center. 

6. A paper record of the completed work order is distributed to 
lmos. Either the load generic or the on-line generic is used to input 
the data, depending on the magnitude and type of change. 

Field experience indicates that, on the average, work order activity 
accounts for about one-fourth the data base change activity incurred 
by service orders (in terms of customer lines affected per year). 

When service order and work order activities are combined, it is 
estimated that 20 megabytes of data in the typical lmos host data base 
is modified in some way every working day. 
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V. SUMMARY 

The data base system of lmos has evolved over several years. 
Among the lessons learned are that it pays to install a working 
prototype system in more than one boc and to plan to make revisions 
based on field experience. An interface with the boc service order 
process is a critical interface, and a mechanized work order interface 
would have been beneficial. In addition, the fixed length data base 
fields and storage attributes (e.g., packed binary) for selected data 
items have resulted in a more rigid data base design than we now find 
desirable. It is suggested that future data base systems be designed 
with the view that data items can change in format, length, and 
attributes. 
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